@llvm/pr-subscribers-lld

@llvm/pr-subscribers-lld-elf

Author: Mingjie Xu (Enna1)

diff --git a/lld/ELF/Arch/X86_64.cpp b/lld/ELF/Arch/X86_64.cpp
index 163505102d0ec..488f4803b2cb4 100644
--- a/lld/ELF/Arch/X86_64.cpp
+++ b/lld/ELF/Arch/X86_64.cpp
@@ -320,6 +320,8 @@ bool X86_64::deleteFallThruJmpInsn(InputSection &is, InputFile *file,
 bool X86_64::relaxOnce(int pass) const {
   uint64_t minVA = UINT64_MAX, maxVA = 0;
   for (OutputSection *osec : ctx.outputSections) {
+    if (!(osec->flags & SHF_ALLOC))
+      continue;
     minVA = std::min(minVA, osec->addr);
     maxVA = std::max(maxVA, osec->addr + osec->size);
   }

This is correct but can you edit /x86-64-gotpc-relax-too-far.s to make this testable?

Thanks for the review!

This is correct but can you edit /x86-64-gotpc-relax-too-far.s to make this testable?

Tried but didn't make it...

The max VA and max VA difference checks are for early return.
The real decision for not relaxing R_X86_64_(REX_)GOTPCRELX is made by checking !isInt<32>(getRelocTargetVA).
Even if max VA or max VA difference in -pie/-shared is >= 2^31 (say the size of .strtab section is 2^31), isInt<32>(getRelocTargetVA) still can be true and R_X86_64_(REX_)GOTPCRELX will be relaxed.
I thinks current implementation doesn't have correctnees issue, but this change can remove some redundant isInt<32>(getRelocTargetVA) checks, so I didn't come up how to extend /x86-64-gotpc-relax-too-far.s to test this.

Do you have any suggestions? Thanks!

You are right that the SHF_ALLOC condition just skips some check and does not change the behavior. Then why does it matter? Do you find a scenario where having the condition improves performance?

I'm looking for strategies that alleviate relocation overflow pressure. While trying to understand 9d6ec28 and f3c4dae, I found the max VA difference takes non-SHF_ALLOC sections into account, which is a bit confusing.

Do you find a scenario where having the condition improves performance?

I will test with internal cases to see if there is any performance improvement.